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1. Introduction 


The Unique Identification Authority of India (UIDAI) has been created, with the mandate of providing a 
Unique Identity (Aadhaar) to all Indian residents. The UIDAI proposes to provide online authentication 
using demographic and biometric data. 

Aadhaar seeding is a process by which UIDs of residents are included in the service delivery database of 
service providers for enabling Aadhaar based authentication during service delivery. As an example, 
MNREGA will require authentication before payout therefore in such a scenario, it will be essential to 
map UID of the resident with MNREGA Job Card number and other demographic information. Similarly, 
banks and insurance carriers may want to map Aadhaar numbers of all their customers. The objective is 
not to replace the currently used unique identifier of the customers/ residents/ beneficiaries with 
Aadhaar but the objective is to seamlessly enable Aadhaar authentication without impacting any other 
interface that the service providers maintain with their customers. 


Aadhaar "authentication" means the process wherein Aadhaar Number; along with other 
attributes, including biometrics, are submitted to the Central Identities Data Repository (CIDR) for 
its verification on the basis of information or data or documents available with it. UIDAI will provide an 
online service to support this process. Aadhaar authentication service only responds with a "yes/no" and 
no personal identity information is returned as part of the response. 


2. Terminologies 


Before reading the document, it is important that the terms mentioned in this section are understood 
very well as they are used very frequently in subsequent sections without any further explanation. 


Terminology 

Description 

EID UID Mapping 
XML file 

A file generated by the CIDR after creation of Aadhaar number. It contains one or more 
pairs of EID and UID related to residents enrolled by a registrar. This file is available on 
Aadhaar portal for download by registrars and their authorized representatives 

KYR 

KYR is a set of mandatory information pertaining to residents. It includes mandatory details 
like Name, Date of Birth/ Age, Address and Gender along with few optional fields like email 
Id, mobile number etc. 

KYR+ 

This is the additional information, apart from mandatory KYR, captured by the registrar at 
the time of enrolment. Ex. MGNREGA Job Card Number, Ration card number etc. 

Service Delivery 

Database 

Database containing resident records among other types of master data/ transactional data 
which a service provider maintains to deliver its services. Ex, Ministry of Rural Development 
maintains a database which contains resident records in rural areas to operationalize the 
MGNREGA program 
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3. Aadhaar Seeding Strategy 

At the outset, it is to be noted that strategy for Aadhaar seeding is a combination of several sub¬ 
strategies and no one solution will apply to all cases. Therefore it is essential that every seeding process 
is thoroughly analyzed and planned before proceeding with actual seeding. While it is the responsibility 
of the service providers to seed their service delivery databases with Aadhaar, UIDAI will support by 
providing necessary tools, expertise, best practices and consulting advisory on request. 

Why Aadhaar Seeding is required 

Going forward, Aadhaar will form the basic, universal identity infrastructure over which registrars, 
government and other service providers across the country will be able to build their identity-based 
applications. These features in turn are expected to serve a developmental mandate to potentially 
achieve multiple transformational benefits of development and equitable growth through: 

1. Proper identification leading to better targeting of development schemes provided by 
government and private sector 

2. Ensuring that all fake, duplicate and ghost records are weeded out from databases so that 
leakages resulting from such records are avoided. 

3. Increased reach and efficiency in delivering many goods and services like PDS, banking and 
financial services, telecom, health, insurance, education etc. 

4. No repeated KYC checks for residents 

One critical input for leveraging Aadhaar authentication is Aadhaar number (UID) itself which needs to 
be captured and stored along with the current unique identifier (Customer Id/ Beneficiary Id etc.) in 
service delivery databases. At the time of authentication, the mapped UID in service delivery database 
will be used to authenticate therefore it is essential that Aadhaar seeding is performed. 

Pre-requisites to Aadhaar Seeding 

Refer the diagram here; 
seeding process has to be 
necessarily preceded by 
Data Digitization and Data 
Centralization. 

Data Digitization 

essentially means collation 
of service delivery data in 
an electronic format 
(database/excel or similar) 
from where data can be 
retrieved using standard 



Data Digitization may be done 
using Aadhaar Data or existing 
Department Data. Data maybe 
cleaned over a period of time 
usingsimple rules. 


■ Data Centralization does not 
necessarily mean collatingall 
data at one physical location. 

• Software Application Users 
with Authorized Access should 
be able to access data online in 
a seam less fash ion while 
providing service/benefit to 
residents. 


Aadhaar Seedingand Data 
Centralization do not follow 
any particular order, and any 
activity may precede another, 
or both activities may run in 
parallel. 
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SQL queries. UIDAI suggests use of a RDBMS (MySQL/ SQL Server/ Oracle/ Sybase/ DB2 and similar). It is 
also important that personal identity data slowly becomes consistent across multiple systems. Aadhaar 
is also an initiative to standardize personal identity information, and Aadhaar data may be used to clean 
the existing data. 

Data Centralization primarily manages 
availability and accessibility of 
distributed service delivery data. The 
objective here is that the seeding 
process/ utility should be able to 
access the service delivery data and all 
related information in at least the 
read-only mode. Example: In a state, 
pensioners' data may be available in 
data silos across districts. A 
consolidated view of the entire data 
would facilitate the social welfare 
department of the state to improve the 
service delivery in their programs, while also being able to ensure that the same person is not availing 
double benefits from two different districts. In case, service delivery data is already digitized and 
centralized then no action is required from seeding perspective. 

Seeding Strategies 

Primarily there are two ways of seeding of service delivery database with Aadhaar number, Top-Down 
method and Organic method where former method uses enrolment information, available in KYR+ and 
EID/UID files as input whereas latter requires the service provider contact the resident or vice-versa for 
updation of Aadhaar number, after the resident goes through a seeding process decided by a service 
provider. 

Top-down Seeding 

This is a method by which one or more KYR and KYR+ fields in KYR+ database are compared with the 
equivalent fields in service delivery database in order to find a suitable match. Upon finding a match 
Aadhaar number from KYR+ database is seeded into the service delivery database. Consider an example 
where MGNREGA Job Card number was captured as KYR+ field at the time of the enrolment. The field 
Job Card Number along with resident name can then be used to find a matching unique record in 
MGNREGA database. Below diagram illustrates this scenario: 


OPTION 1 

Using KYR+ 
Data of 
Registrars 


» Use KYR+Database files and merge EID 
into Department Database (with 
Department identifier as connecting key) 

► Use EID-UID mapping file to merge UID into 
Department Database (with EID as 
connecting key) 



1 Seeding of Aadhaar Number in service 
Delivery Database one by one, after 
collecting Aadhaar Number from residents 
* The same may be done in presence of 
absence of residents, with or without 
authentication, as required by the service 
provider 
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KYR+ Tabic built using EID-UIDfilcs 
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Another possible scenario is where there is no relevant KYR+ field captured, example customer Id with a 
telecom company. In such cases, one or more KYR fields should be used for matching 



Take the case of Ravi RurTTaPr ^ 
Customer ld-E87987 

1. Name match 100% 

2. DoB match 100% 

3. Address partial match 60% 

4. Mobile No match 100% 

Given the highest match score that 
Ravi Kumar's record in Telecom 
database returns, UIDfrom KYR 
table is seeded into the UID column 
of Telecom service delivery table 


Customer Tpble of Telecom company's database 
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As shown above, KYR fields (Name, DoB, Age, Address) from KYR Table are matched with the KYR 
equivalent field in the service delivery table and based on the match percentage of individual fields, an 
overall match score is calculated. It is ideal to have 100% match for seeding to take place but that 
happens rarely therefore it can be assumed that if the match score exceeds a pre-defined threshold 
(possibly 80%) then a match may take place. 

In the diagram above KYR table, built using EID-UID XML files, has been used as reference table, 
however reference database can also be created using KYR+ data as well. Advantage of using KYR+ data 
is that it always contains KYR data, except the UID, along with additional information as mandated by 
the registrar. As an example, registrars may make it mandatory to capture residents' MGNREGA Job 
Card number or PDS Ration Card number at the time of enrolment. Capturing of additional information 
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makes seeding simple as unique identifiers thus captured can be used for matching of records between 
KYR+ and service delivery tables whose unique has been captured as an additional information during 
enrolment - a Job Card number or Ration card number or any other unique identifiers are ideal 
conditions for matching to take place. 


Execution Steps 

Execution steps indicated below assume usage of Ginger, seeding utility developed by UIDAI in-house. 
Refer Appendix-1 for details related to the tool. Below diagrams gives step-wise approach of seeding 
using KYR and KYR+ data 

r -\ 


Collate all EID UID data from individual XML files into a database 
table. ( Caution: Do not pick records where the status is "Rejected") 


De-duplication and Cleansing of the service delivery data, if need 
arises. It should be ascertained that the KYR equivalent fields have 
data in proper and consistent format (ex. nulls are okay but date of 
birth as character field is not okay.) 


^ A 


Insert a new column for storing UID in the service delivery table 


Set matching threshold and carry out the matching process (tool 
based or manual is the call that service provider has to make) 


^ A 


Upon finding a match, seed UID from KYR table into the matched 
record in service delivery table 


V 




Seeding using KYR Data (obtained from EID-UID XML files) 
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Similarly, collate all KYR+ data into a database table. Look for "reject" 
flag, if any, those records need to be excluded from load. Create a 
new column "UID" and seed it from KYR table (step 1) based on the 
EID, which serves as foreign key 


De-duplication and Cleansing of the service delivery data, if need 
arises. It should be ascertained that the KYR equivalent fields have 
data in proper and consistent format (ex. nulls are okay but date of 
birth as character field is not okay.) 





Insert a new column for storing UID in the service delivery table 


^ A 


Set matching threshold and carry out the matching process with 
reference to KYR+ table (tool based or manual is the call that service 
provider has to make) 


Seeding using KYR+ Data 


Organic Seeding 

Organic seeding is a method which involves creation of touch points with the residents where the 
residents voluntarily or in response to service provider's call initiate inclusion of their UID in service 
delivery databases. This approach can be implemented in an interactive mode or in batch modes. 


A 


Interactive 

Mode 




• Resident approaches department for following reason: 

• To avail department specific benefits scheme and/ or services. 
These touch points can be in the field or department offices 
(desktop). 

• Special drive by department for Aadhaar registration for specific 
benefits & services. 

• Resident voluntarily approaches the department to register 
Aadhaar for the specific service. 


Batch 

Mode 




• Department provides list of data pair (Aadhaar, Dept KYR+) to be 
processed in a batch mode 

• New scheme, where off-line data entry is done from an application 
form submitted by the resident. 

• New registration in a existing scheme. 


The touch points, as mentioned above can be created in various ways as illustrated below. A 
department can leverage one or more channels of communication with the residents in order to capture 
their Aadhaar numbers 
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Document 
collection 
Camps @ GP 



Email 



SMS 




Operator = sted 
Update® GP 



IVR 
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43 

¥ 
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Channel 

Description 

Document Collection 
at touch points 

Residents are expected to hand over copies of Aadhaar letter and registration 
form with the service provider (ex. Ration card). Service provider later updates 
the service delivery database based on the information supplied 

SMS 

Service provider enables a SMS based application. Residents are expected to 
send a SMS containing the Aadhaar number and registration number with the 
service provider. Ex UPD <Aadhaar Number> <Ration Card Number> is sent to a 
number 59999 (illustrative only). The application at the backend seeds the 
Aadhaar number into the database by using the Ration Card number as key. For 
verification of information supplied service provider needs to conduct 
demographic authentication post seeding (discussed later) 

Operator assisted 
update @ touch 
points 

Service provider enables direct seeding of Aadhaar number at resident touch 
points where residents are expected to come along with supporting documents 
- Aadhaar letter and service registration document. The resident is 
authenticated both demographically and biometrically before Aadhaar number 
of the resident is seeded in service delivery database 

Email 

Similar to the SMS based approach. Email needs to be sent to an email id in a 
pre-defined format along with scanned copies of supporting documents as 
attachments. Upon receiving the email, the backend application extracts 
required information from the email and seeds database appropriately. In case 
of a failure, resident is informed by a reply email 

Post/ Courier 

Similar to Document collection approach, however in this case collection of 
documents happens through post/ courier 

IVR 

A telephone based IVR application that captures Aadhaar number and 

Registration number in an interactive manner. Upon capturing the required 
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Channel 

Description 


information backend application seeds service delivery database appropriately. 
Demographic authentication should be conducted post seeding for verification 

Self-service Web 

Portal 

Service Provider may open up a web portal for residents to update their 
Beneficiary Identifier Number / Account Number, along with Aadhaar number. 
Service Providers may do a demographic authentication at the back-end before 
updating their database with Aadhaar number. 


Refer Appendix 2 for a detailed approach of seeding Aadhaar into bank's database by means of ATMs 
and micro-ATMS. 

Demographic and Biometric Authentication 

After the completion of Top-down seeding and Organic seeding where no direct update of service 
delivery database was enabled, it is highly recommended that demographic authentication of data in 
service delivery database is conducted. This is to ensure that seeding has indeed been done correctly. In 
cases where demographic authentication fails, service provider should investigate into the reasons of 
failure of authentication. Some of the reasons of failure are: 

1. Aadhaar seeded into an incorrect record. This may potentially happen in the cases of partial or 
fuzzy match 

2. Resident updated his/ her KYR data in CIDR (due to marriage, change of address, updation of 
incorrect information) 

3. Incomplete or incorrect KYR+ data captured during enrolment (ex. incorrect MGNREGA Job card 
number) 

Enabling of Biometric authentication is required at operator assisted touch-points where a direct update 
of service delivery database takes place. 

Refer Ginger, seeding utility, in Appendix-1 for more details on usage of demographic authentication 
module. 


A pre-requisite to conducting Aadhaar authentication is that the service provider should be an AUA 
(Aadhaar User Agency). 


Authentication User Agency (AUA): An organization or an entity using Aadhaar authentication as 
part of its applications to provide services to residents. Examples include Government 
Departments, Banks, and other public or private organizations. All AUAs (Authentication User Agencies) 
must be registered within Aadhaar authentication server to perform secure authentication. 


Sub-AUA (SA): An organization or a department or an entity having a business relationship with 
AUA offering specific services in a particular domain. All authentication requests emerging from an 
AUA contains the information on the specific SA. For example, a specific bank providing Aadhaar enabled 
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payment transaction through NPCI as the AUA becomes the SA. Similarly, a state government being an 
AUA can have the health department under them as the SA using Aadhaar authentication while 
providing healthcare benefits. 

Authentication Service Agency (ASA): An organization or an entity providing secure leased line 
*3 connectivity to UIDAI's data centers for transmitting authentication requests from various AUAs. 
All connections to production authentication servers must come through private and secure connection 
through ASAs. Those AUAs who wish to provide their connectivity can become their own ASA whereas 
smaller AUAs who do not wish to create direct leased line connection to UIDAI's data centers can use an 
ASA. 

Common Challenges during Seeding 

It is important to understand the common challenges during seeding so that necessary precautions can 
be taken early during planning. Below are the some of the challenges that seeding team should be 
aware of and develop necessary processes/ workarounds to overcome them. 

1. Complete data is not captured in service delivery databases: Data is often entered manually by 
semi-skilled data entry operators which results in incomplete and incorrect data. Lack of 
adequate QA process by service provider too contributes to the problem. Data digitization 
strategy should address this potential issue 

2. Similar information across different data sources do not have exact match between them: It 

has been observed that same data across different tables are not entered similarly. Take the 
case of names MV Ramachandran and Madanapalli Venkata Ramachandran that refer to same 
person. Seeding involves exact/ partial match of various data fields therefore such issues should 
be handled during data cleansing and normalization 

3. Data in service delivery database is in a local language: Matching of data in same language can 
be done with standard comparison algorithms but if the language (e.g. 3TRcT vs. India) no way a 

match can be made. If a match is to be made then the algorithms need to be made extremely 
intelligent and complex unless data level changes made in the database 

4. All the required data is not available: Careful planning and coordination with support groups 
need to be done. As an example, codec information should be made available in cases where 
only codes are stored (often in Gender field, Male is stored as 1 and Female as 2) 

5. Normally available tools become incapable to handle high volume of data: Normally everyone 
prefers using Microsoft Excel for data handling. However, it has been observed that after few 
thousand records inserted into excel sheet, response time of the tool deteriorates significantly. 
In such cases alternatives like use of database tools should be thought of - e.g. import data into 
a database (MySQL, MS SQL Server, Oracle so on and so forth) 

6. Mobilization of Residents: In the case of Organic Seeding, mobilization of residents is required 
in order to complete seeding. Multi-channel organic seeding approach needs to be employed for 
effective mobilization 
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As stated earlier, it is recommended that seeding teams share their experience with UIDAI team 
(rakesh.ranjan@uidai.gov.in) at HQ, Delhi so that seeding approach/ methodology, learning and best 
practices can be published to other teams involved in seeding. 


4. Case Study 1 - Seeding of Aadhaar in RoR @ Tripura 


Owner 

Organization 

Govt, of Tripura 

Scope of Work 

Seeding of Aadhaar number into RoR (Register of Ordinary Residents) database 

Location 

Agartala 

Schedule 

Nov'11 to Mar'12 

Stakeholders 

1. Government of Tripura 

2. UID Authority of India 

3. NIC 

Roles and 
Responsibilities 

Gov. of Tripura (GoT), owner of the project 

1. NIC -Provide access to RoR database 

2. Registrar - Provide EID-UID files and KYR+ files available with the registrar 

3. GoT - Provide necessary hardware and software licenses to execute the 
seeding process 

4. GoT - Provide leadership support in resolving bottlenecks 

5. GoT - Provide data entry operators for data entry into RoR 

6. GoT - Execute seeding steps 

7. GoT - Prepare Data Digitization Strategy 

8. GoT/ NIC - Prepare Data Centralization Strategy 

9. GoT/ UIDAI - Prepare Seeding Strategy 


UIDAI, the implementation partner 

1. Participate in analysis of enrolment and RoR data 

2. Conduct trainings for the seeding execution team 

3. Provide oversight during seeding 

4. Conduct post-seeding review 

5. Prepare closure report 

Digitization 

Strategy 

Tripura is one of the few states that have taken the initiative to create a register of 
all residents in the state called RoR (Register of Ordinary Residents). As part of this 
program it is intended that details of all 35L residents of the state are stored in one 
database. Therefore from digitization perspective, the state is doing everything right 
except for the fact that only 9L/35L records have been created in RoR as of Oct '11. 
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It is expected that by April 2012 records of 35L residents will be digitized 


Centralization In order to carry out seeding process, KYR, KYR+ and RoR data will be needed. EID- 

Strategy UID files will be used to obtain KYR data while KYR+ .mdb database files will be used 

to obtain KYR+ data. Access to RoR database and data dumps has already been 
provided by the Gov. of Tripura. 

Using the EID-UID extractor program, KYR data that includes UID as well will be 
extracted and uploaded to a SQL Server database. All KYR+ .mdb files be merged to 
create one database on the same SQL Server instance 


Seeding Strategy It has been proposed by GoT that seeding should commence from Gram Panchayats 
so that the welfare programs targeting rural population, ex MGNREGA, are 
benefited before any other program. Below flow diagram explains the complete 
seeding strategy 



Seeding 


\/ 

Demographic 


Authentication 


• Ensure all the names are entered in Bangla. There were few cases where names were entered in English 

• Ensure all the DoBs are entered as a date. In case only the age is known then convert that to a date as 
"l/l/<derived year>". Ex 34 years of age will be converted to 1/1/1977 

• De-duplication of records, Panchayat-wise 


• For every record in KYR+ database, based on the EID find the UID in EID-UID database. Update the record 

• Split by means of database query the RoR records Gram Panchayat-wise 

• Using Ginger, for every record in step 2, match the resident name and location Id in the KYR+ database 

• Manually select the matching records by verifying the name, date of birth, address and other possible 
fields 

• Mark the record as seeded 


• Post seeding , run the demographic authentication utility available in Ginger to validate seeded data 

• In case of demographic authentication failure mark the records for review 

• Re-run biometric authentication post review of such records 


Ginger with MSSQL Server database, RoR on MSSQL Server database, Excel 


Tools 


Risks/ Mitigation 


1. As of Oct 11 coverage of RoR is approx. 50% of state's population. All the 
analysis and recommendation is based on this set of data. New issues not 
observed so far that might come later will potentially impact the seeding 
strategy 


Issues/ 

Resolution 


Issue 


In significant number of RoR records 
date of birth recorded as year only 


Resolution 


1. Converted data type of field to 
'Date'. 

2. Converted all variants of DoB to 
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dates. Ex 1956 was changed to 
1/1/1956 

3. Different date formats were 
changed to one format of "yyyy- 
MM-dd" for consistency and 
enabling matching using this 
field 


Only first 14 digits of EID captured in 

RoR 

No change to EID field but this EID with 
Name, DoB gave a unique match 

Best Practices 

1. Involvement of Panchayat level officials for seeding and verification post- 
seeding. This approach is based on the assumption that Panchayat 
leadership is aware of every resident in its area of operation 

2. Start small and then expand. Began seeding of data pertaining to 

Panchayats with population not exceeding 1500. This helped in identifying 
the ground level challenges and thus identifying mitigation strategies 

Learning 


Assets shared/ 
can be shared 
with UIDAI 


IPR Details 


Point of Contact 

Mr. Kiran Gitte, IAS 

DM and Collector 

West Tripura District 

Agartala 



Mr. Rakesh Ranjan 

Senior Manager (Applications) 

UID Authority of India 
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5. Case Study 2 -Aadhaar enabled LPG Delivery pilot with IOCL 


Scope of Work 

1. Integrate Aadhaar in Oil Marketing Companies Database to remove, 
duplicates and ghost 

2. Perform Aadhaar based Biometric Authentication at time of delivery of 
cylinder 

Location 

Mysore, Hyderabad and Pune 

Schedule 

As of Feb 2012 - In Progress 

Stakeholders 

• UIDAI 

• Residents (Consumers of LPG) 

• OMCs 

• OMCs' Distributors 

Roles and 
Responsibilities 

• UIDAI - to provide Authentication Service 

• OMC - to build a system for Aadhaar Integration across OMCs 

• Distributor - to perform authentication at time of delivery with Pos Device 

• Resident (LPG Consumer) - to provide Aadhaar number and to participate in 
biometric authentication at time of acceptance of delivery. 

Digitization 

Strategy 

Oil Marketing Companies have over many years undertaken various 
computerization initiatives for delivery of Domestic LPG. Indian Oil Corporation 
Limited uses software package called 'Indsoft', Bharat Petroleum Corporation 
Limited uses 'nLPGnext' and Hindustan Petroleum Corporation Limited uses 'DCMS'. 
Through these initiatives, digitized customer data was already available with OMCs. 
OMCs had to seed in or rather associate Aadhaar data with its customer database. 
OMCs developed a common integrated database which associated Aadhaar 
numbers of connection owner, family members and authorized representative with 
identified unique key for each customer of OMC for domestic LPG. Identified Unique 
key (Candidate Primary Key) was used for all business transactions and Aadhaar was 
used for biometric authentication 

Centralization 

Strategy 

All OMCs customer databases to talk to each other, for removing duplicate across 
the OMCs. SI hired to build the integration software 
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Envisaged scenario for UID aligned connection registration and release process for existing and new customers. 



Seeding Strategy OMCs originally planned for three pronged strategy: 

• Associating Aadhaar data from KYR+ data received from Enrolment 
Agenc(ies); 

• Associating Aadhaar data from KYR+ data received from other Registrars; 

• Organic seeding of the data 

For Pilot, only Organic seeding was undertaken because 

• OMCs did not appoint Enrolment Agencies in cities identified for Pilot as other 
Registrars were already present for enrolments 

• KYR+ data received from other Registrars had very small subset of LPG 
customers providing information sought by OMCs 

Following is the process being followed by OMCs for organic data seeding 
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OMC sands form 


Customer fills the 

raquasfing required 


form, attaches 

information to 


required documents 

customar along with 


A sends to P.O. Bo* 

self addressed 


as printed on self* 

enveioot. 




Sand corractad 
formi to (GATE* 


OMC to arrange to 


Return to OMC 

collect 


along with 

mrssmg/rncomplete/ 


remarks and 

multilingual 


statistics 

information/ 



incorrect 




Genarste MIS .sand 
to OMC tor daelsidn 
and update cuttomrr 
maitar 


Generate MIS .send 
to OMC ifw) updAt* 


Customer master 

Yes 


Draft | Pag* i 



iU Erns t & Young 

to ItmAHl IA> 


Tools 


1. Separate database associating Connection Owner details and Aadhaar numbers 

2. Manual Excel based entry for Aadhaar numbers for self, family and authorized 
representative 

3. Batch upload utility for uploading the Aadhaar data 

4. Bulk Demographic Authentication with CIDR of Aadhaar data collected 

5. EID to UID update through excel macros 

6. Batch upload of validated data 


Risks/ Mitigation 


SL 

No 

Risk 

Mitigation Strategy 

1 

Delay in mobilization of customers to 
provide UID details 

Proper communication plan for 

the customers 

2 

Incomplete forms submitted by 

customers 

Re - approaching the customers 

to submit the data 

3 

Misplacing of envelops 

Tracking of envelops 

4 

Form filled in local language 

UID letters asked to be attached 

along with the form 

5 

Incorrect UIDs entered in the Form 

Shall be filtered out during 
demographic bulk authentication 
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6 

EID provided 

EID to UID conversion through 

macros 

7 

Incorrect UID data entry 

Shall be filtered out during 
demographic bulk 

authentication. Need to be 

verified with hard copies. If 
found incorrect in hard copy as 
well, need to approach the 
customer for providing the data 
again. 

8 

Bulk demographic authentication 

failure 

Need to be verified with hard 

copies. If found incorrect in hard 
copy as well, need to approach 
the customer for providing the 
data again. 

9. 

Non availability of KYR+ 

Fall back on Organic seeding 

10 

Incomplete availability of KYR+ 

Fall back on Organic seeding 

11 

Low percentage of enrollers providing 

KYR+ 

Fall back on Organic seeding 

12 

Customers not attaching UID letters 
along with the forms 

Depend on hard copies for 

information. If found incorrect in 

hard copy as well, need to 
approach the customer for 
providing the data again 

13 

Customers non willingness to provide 
information/fill the form 

Plan for various modes of 

providing UID information e.g. 
website, sms etc. 


Issues/ 

Resolution 
Best Practices 

Start small and expand 

The project involves three OMCs viz. IOCL, BPCL and HPCL, Different Databases/ 
Database schemas amongst the three OMCs, Different System architecture for each 
OMC, Different software application implemented at each OMC, Receipt of KYR+ 
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input data from Enrolment agencies and other Registrars 

To achieve an effective data migration procedure, data in the existing IT systems 
needed to be associated and uniquely identified through system developed by the 
SI (System Integrator). Accordingly data was mapped to the new system providing a 
design for data extraction and data loading. 

Data Migration strategy 

Following is the three-pronged strategy which was adopted for the data migration 
for OMCs: 

a) Incremental cutover: Since the current project is a pilot for a subsequent 
nationwide rollout, the data will be moved to the target environment by 
migrating only discrete parts of the business and associated data. However, 
current data in existing systems will continue to co-exist. 

b) Data Enrichment (KYR+ association): Manual intervention was required for 
this step followed by a maker checker control to check the integrity of the 
enriched data. Also, temporary storage solution was used that allows users 
to extract data from legacy system (s) and perform various transformations 
to get it into a fit state for loading into the target environment. 

c) Bi-directional Synchronization: Changes in the old system were allowed to 
flow to the new target system and changes to the target system to flow 
back to the old system. Since, there is an envisaged update to customer 
record, that is, addition of customer UID, household or family details & their 
UIDs, nomination of authorized personnel & their UIDs; it was needed to 
post connection owner's UID changes back to the old system that performs 
legacy operations on same account. 


Learning Start early 

As done in OMCs, data digitization process should be started early in the project so 
that by the time application development is complete and stabilizes, sufficient data 
is available in the system for testing. 

Streamlined Digitization process 

Streamlined flow for data digitization should be in place when multiple stakeholders 
are involved, with clearly defined roles and responsibilities. 

Periodic MIS 

Periodic MIS to track flow of data digitization and snapshot into data digitization 
process helps monitoring digitization activities. MIS was sought containing following 
information 

a) Tracking of communication sent to customer 

b) Tracking of envelops received 

c) Tracking of digitized data 

d) Tracking of non-digitized data along with reasoning 


Assets shared/ 1. Customer Form 
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can be shared 
with UIDAI 

2. System Requirement Specification 

3. Functional Requirement Specification 

4. MIS Template 

5. Digitization Templates/Formats 

IPR Details 



Point of Contact Mr. P Jayadevan 

Chief Manager, LPG sales, IOCL 
* email Id will be provided on request 


6. Appendix 1 - Ginger (Seeding Utility) 


Seeding process typically involves data extraction, consolidation, normalization and matching. For 
performing these activities, UIDAI has developed Ginger, an in-house tool which can be used by service 
providers after signing an agreement with UIDAI in order to ensure that the tool is not used for purposes 
other than intended for. Features of this tool include 


Feature Description 


Extract EID- 

UID Data 

Extracts node data from EID-UID XML files and inserts into a database. It helps build 
the reference tables that contains all the UID generated along with KYR data for the 
target population 

KYR+ merge 
utility 

KYR+ files are generated in various formats e.g. txt, mdb etc. In the current release the 
tool will be able to handle only the mdb files however support for other formats will be 
added later 

Matching 

Utility 

This utility can help in identifying matching records across service delivery database 
and KYR+ database. Upon finding match, user can mark the matched record which can 
be then used to generate a SQL script for actual database update post QA review of 
mappings by a competent authority. 

Important: This tool does not perform automatic seedinq owinq to security reasons 

Demographic 

Authentication 

This utility is not available in the current release. Objective of the tool is to perform 
authentication on demographic data after completion of seeding. Successful 
authentication would mean that the resident/ customer data in service database has 
been synced up with data in CIDR 
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Match and Seed Module 


M G 


Upload EID-UID Files 




Li) Match and Seed 

Query Panel 


WHERE locationld like '1601201026%' and uidno is null ORDER BY locationlcT 


Query box to select set of residents 
(location-wise is one such criterion) 


Enrolment ID 
Not Available 


□ Family Id/ Member Cld |T] Member Name 

16012010260440 SRim Ttvsnisr 

16012010260440-1 


16012010260440 

16012010260440-2 


16012010260440 


□ Date of Birth 
1940-04-03 


~ aj Create a mapping of KYR+ record and the 
matching resident record in service delivery 
table 


this r ' _ wui a Export T, 


Resident records as available in service 
delivery database 



Table Clear Table Search Keyword <Search> 


Matching records from KYR or KYR+ data 
table (configurable) 



Search Results [Aadhaar Mappings 


Query execution completed 


Using this module, one or more KYR equivalent fields (Name, Date of Birth, Age, Gender) from resident 
records in service delivery database are matched with equivalent fields in KYR+ or KYR records 
(configurable) - refer the user manual for usage guidelines. The mappings thus created can be exported 
to excel for further review and approval by a competent authority appointed by the service provider. It 
is to be noted that functionality of match and seed module is limited only to creation of mappings and 
their export. It is expected that based on mapped data, service providers create custom SQL scripts to 
update the service delivery database 
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EID-UID Upload Module 

BGi 




GINGER 


Upload EID-UID Files 


Upload EID-UID KYR Data XML files 


Select 

Upload 

Export 

Clear 

Directory 

KYR Files 

as CSV 

Log 


W 



ielected Directory - C: VJsersVakesh.ranjanpesktop\Contents\archive 


Input Filename 

Registrar Id 

Report Date 

Total Enrollments 

Valid Records 

Rejected Records 

Status 



116 1144772867670417 2... 

116 

2011-05-29 

1158 

0 

0 

PARSED SUCCESSFULLY 

> 


116 1199310183425764 2... 

116 

2011-05-13 

787 

0 

0 

PARSED SUCCESSFULLY 



116 1345026355955574 2... 

116 

2010-12-10 

3717 

0 

0 

PARSED SUCCESSFULLY 



116 594192335959231 20... 

116 

2011-09-17 

1696 

0 

0 

PARSED SUCCESSFULLY 



116 626390555275417 20... 

116 

2011-05-23 

1403 

0 

0 

PARSED SUCCESSFULLY 



116 82Q325751344764 20... 

116 

2011-05-09 

369 

0 

0 

PARSED SUCCESSFULLY 



116 820355696579764 20... 

116 

2011-05-09 

272 

0 

0 

PARSED SUCCESSFULLY 



116 820742799592764 20. .. 

116 

2011-05-09 

972 

0 

0 

PARSED SUCCESSFULLY 



116 821031420267764 20... 

116 

2011-05-09 

862 

0 

0 

PARSED SUCCESSFULLY 



116 821472289901764 20... 

116 

2011-05-09 

1235 

0 

0 

PARSED SUCCESSFULLY 



116 822224869539764 20... 

116 

2011-05-09 

788 

0 

0 

PARSED SUCCESSFULLY 

= 


116 823413195557764 20... 

116 

2011-05-09 

617 

0 

0 

PARSED SUCCESSFULLY 



116 823883844457764 20.. . 

116 

2011-05-09 

304 

0 

0 

PARSED SUCCESSFULLY 



116 824368485262764 20... 

116 

2011-05-09 

1388 

0 

0 

PARSED SUCCESSFULLY 



116 825119698788764 20... 

116 

2011-05-09 

858 

0 

0 

PARSED SUCCESSFULLY 



116 825374004445764 20... 

116 

2011-05-09 

379 

0 

0 

PARSED SUCCESSFULLY 



116 825446584312764 20... 

116 

2011-05-09 

952 

0 

0 

PARSED SUCCESSFULLY 



116 825526895141764 20... 

116 

2011-05-09 

1329 

0 

0 

PARSED SUCCESSFULLY 



116 825691991254764 20... 

116 

2011-05-09 

1479 

0 

0 

PARSED SUCCESSFULLY 



116 827195307229764 20... 

116 

2011-05-09 

3171 

0 

0 

PARSED SUCCESSFULLY 

— 


116 896466845981764 20... 

116 

2011-05-10 

724 

0 

0 

PARSED SUCCESSFULLY 



116 896497619973764 20... 

116 

2011-05-10 

615 

0 

0 

PARSED SUCCESSFULLY 



116 896546656580764 20... 

116 

2011-05-10 

315 

0 

0 

PARSED SUCCESSFULLY 



116 897845433499764 20... 

116 

2011-05-10 

1329 

0 

0 

PARSED SUCCESSFULLY 



116 901940825246764 20. .. 

116 

2011-05-10 

1051 

0 

0 

PARSED SUCCESSFULLY 



116 905977961571764 20... 

116 

2011-05-10 

492 

0 

0 

PARSED SUCCESSFULLY 



116 906398305968764 20.. . 

116 

2011-05-10 

921 

0 

0 

PARSED SUCCESSFULLY 



116 909706979761764 20... 

116 

2011-05-10 

1799 

0 

0 

PAR SFn SI irCFSSR 111Y 





1 Upload Progress i Log 


All EID-UID files processed 


Ready 


With the help of this module, EID-UID data from XML files can be uploaded into any database (currently 
mapped to MySQL). It is a multi-threaded utility that simultaneously uploads data from all files resulting 
in very fast upload (on a normal workstation it takes less than 3 min to upload 30,000 records). It also 
produces a reported that contains information related to number of files successfully read, total records 
read, total number of records inserted and total number of records rejected. 
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Demographic Authentication Module 

j[Ging 



Upload EID-UID Files 


Demographic Authe... 


Li) Demographic Authentication 

Load File Data Authenticate Export CSV 


Select File (*.xls) 

C: \Users Vakesh. ranjan desktop Ves. csv 


Ezsii 


MS E t MV 100 — 

O UID 

378809592552 

□ Name 

PS REDDY 

□ Date of Birth 

12-Mar-91 

□ Address 

301 

□ Gender 

M 

□ Status 

AUTH_FAIL 

□ Error Code 

■156579000832 

P SHANTAMMA 

12-Mar-92 

303 

F 

AUTH_FAIL 


148348721266 

P.JANAKI 

12-Mar-93 

305 

M 

AUTH_FAIL 


lo2899480642 

P.SAIBABA REDDY 

12-Mar-94 

307 

F 

AUTH_FAIL 


168718491457 

P.JAYASRI 

12-Mar-95 

309 

M 

AUTH_FAIL 


162095217949 

P.SRIKANT REDDY 

12-Mar-96 

311 

F 

AUTH_FAIL 


890086720754 

SAGAPURAM SURESH 

12-Mar-97 

313 

M 

AUTH_FAIL 


821774478086 

S.SANDHYA 

12-Mar-98 

315 

F 

AUTH_FAIL 


988484582149 

S.VENKATESH 

12-Mar-99 

317 

M 

AUTH_FAIL 


678197039832 

S.SIVANI 

12-Mar-00 

319 

F 

AUTH_FAIL 


936245762712 

P.KRISHNA 

12-Mar-01 

321 

M 

AUTH_FAIL 


765807564267 

P.UMARANI 

12-Mar-02 

323 

F 

AUTH_FAIL 


999999990019 

Shivshankar Choudhury 

13-05-1968 

432 

M 

AUTH_PASS 


999999990026 

Kumar Agarwal 

12-03-1985 

322 

M 

AUTH_PASS 




In order to verify whether seeding has been done accurately, it is essential that the resident records in 
service delivery database are authenticated demographically. Objective of demographic authentication 
is to check whether UID and KYR fields are mapped correctly and are in line with the data in CIDR. 

Post demographic authentication, "Status" column is updated with one of the authentication statuses 
"AUTH_PASS"/"AUTH_FAIL"/"AUTH_ERR". In the case of AUTH_FAIL or AUTH_ERR, error code is also 
indicated that explains the reason for authentication failure which can be used for investigation 
purposes. 

Pre-requisites for conducting demographic authentication are: 

1. Service provider/ government agency has assumed the role of AUA 

2. The agency has either assumed the role of ASA or entered into an agreement with another ASA 
for routing of authentication requests to CIDR 

3. AUA application has been developed that complies with the specification outlined in the 
authentication API document (http://uidai.gov.in/images/FrontPageUpdates/ 
aadhaar_authentication_api_ l_5_revl_ l.pdf). 

The above pre-requisites are mandatory because access to CIDR production data will not be available to 
requesting agency otherwise. 
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7. Appendix 2 - A Bank's approach to Organic Seeding 


Banks may use ATM's and going forward, Micro ATM's to seed Aadhaar numbers of their customers. 
ATM's and Micro-ATM's are the best touch points for bank customers. The following diagram shows the 
seeding of Aadhaar numbers by a bank through its network of ATMs. 

Steps for ATM based seeding 




i p 

digit Aadhaar Number entry 




1 

Cl 


\ fe/ 


a* 

AADHAAR 

l 


Step 1. Resident goes to 
bank ATM for banking 
service 


Step 3. Bank gets Aadhaar 
information 



Step 5. On successful authentication, 

bank seeds Aadhaar Number in the 
customer table of core banking system 




Step 4. Bank sends Aadhaar 
number for Demographic 
Authentication to CIDR. Bank 
uses date of birth match and 
partial name match value set 
at 50% for authentication. 


Steps for Micro-ATM based seeding 

1. Resident should be able to provide three things which may be captured on the micro-ATM 
device namely Aadhaar number. Bank Account Number and Bank's BIN number. The device may 
maintain the mapping of bank name and BIN number, since resident may not know BIN number. 
(Name capture may be optional) 

2. Creation of CSV files at the end of the day (or at any other time period) with list of all records 
captured so far, which can be exported from the device onto a laptop/computer. The file-name 
should reflect the export date-time 

3. Ability to push the relevant records/CSV to corresponding bank based on BIN number. The 
banks should open interfaces to accept such records in a CSV 

4. Banks may do a demographic authentication with partial match (let's say 50 percent) before 
seeding the Aadhaar number in core banking system database 

5. If banks maintain mobile numbers of customers, they should send an SMS to its customers with 
the update. "Your Aadhaar number XXXX XXXX 5302 has been linked to your bank account 
number XXXX XXXX1185. Please contact us in case of any queries". 
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